Manufacturing processes and associated industrial process control systems produce a large amount of process information, and software applications are available that provide access in real-time to such information. One such software package is the PI Server from OSIsoft of San Leandro, Calif. The PI Server acquires, stores, and processes large amounts of process information, enterprise-wide. The PI Server can typically store large amounts of raw measurement data at the original resolution and client application programs provide users throughout the enterprise system access to this real-time information. In some situations, however, the PI Server is located within a secure area (i.e., within an isolated process control network) while the client applications run on computers outside that secure area (i.e,. computers coupled to a separate corporate business network). In this situation, a secondary PI Server can be set up coupled to the business network, with an additional interface which transfers the information from the secure area PI Server (the “primary PI Server”) to the secondary PI Server. Although OSIsoft provides an application (called the “PI to PI Interface”) that allows the transfer of information from a first PI Server to a second PI Server, this interface is relatively insecure because it uses a two-way TCP/IP-based network connection to transfer data from the first PI Server (the source server) to the second PI Server (the receiving server).
Owl Computing Technologies, Inc. (“Owl”) provides a more secure method of transferring data from a primary PI Server within a secure network domain (e.g., NIST level 3) to a secondary PI Server outside the secure network domain (i.e., within a network domain less secure than the secure network domain such as NIST level 2). Such a system 100 is shown in FIG. 1 and uses a one-way data link 110 to transfer information from the primary PI Server 102 in the secure network domain 120 (the area to the left of the dotted line 122) to the secondary PI Server 118 in the less-secure network domain 121 (the area to the right of the dotted line 122). In particular, the primary PI Server 102 runs on a source platform 101 within the secure network domain 120, and is coupled to a first network 104 via a TCP/IP interface 103. An OwlPI application 107 runs on a send server platform 106 which is also coupled to network 104 via a TCP/IP interface 105. The OwlPI application receives information from the primary PI Server 102 and converts the information to UDP packets that are forwarded to MUX 108, which forwards the UDP packets to a transmit application 109. Transmit application 109 is coupled to a receive application 111 in the receive server via a one-way data link 110. The combination of transmit application 109, one-way link 110 and receive application may comprise an Owl Computing Technologies Dual Diode (described in U.S. Pat. No. 8,068,415, the disclosure of which is incorporated herein by reference). Transmit application 109 forwards the UDP packets across the one-way link 110 to receive application 111, which, in turn, forwards the packets to DEMUX 112 for transmission to the OwlPI application 113 running on the receive platform 114. MUX 108 and DEMUX 112 are included because in some situations more than one OwlPI application 107 may be running on send server 106, and thus a corresponding number of OwlPI applications 113 will be running on receive server 215. MUX 108 and DEMUX 112 are used to route information from/to the appropriate corresponding OwlPI applications 107, 113 in such situations. One of ordinary skill in the art will readily recognize that the MUX 108 and DEMUX 112 may be omitted when only one occurrence of the OwlPI application 207 is used. Receive platform is coupled to a second network 116 within the less-secure network domain 121 via a TCP/IP interface 115. The secondary PI Server 118 runs on a destination platform 119, which is coupled to the second network 116 via a TCP/IP interface 117. The OwlPI application 113 receives the UDP packets and converts the information therein into appropriate updates for transmission to secondary PI Server 118.
System 100 continually and repeatedly copies PI database records, snapshot data, digital state tables, and historical archive data from primary PI Server 102 to secondary PI Server 118 using a single UDP connection. The database records (point records) constitute information about the type of data (e.g., floating point, integer, character array, etc.) to be stored in the associated record. Snapshot data constitutes the most recent data for each PI tag. The digital state tables define the states that correspond to the values for digital PI tags (e.g., Open/Closed for a valve or On/Off for a switch). For historical archive data, system 100 continuously transmits a pre-set amount of historical data (e.g., a selected period between 1000 and 50000 minutes). A problem may arise when a particular PI database record is updated at the primary PI Server 102, which may occur when the source of the information for the associated PI tag is updated and the form of such information changes (e.g., from integer to floating point). This PI database record is automatically updated at the secondary PI Server 118, but no notice is given to users accessing such PI tag information via network 116. In some cases, for example, such PI tag information is automatically imported into user spreadsheets or other local databases and may cause errors or inaccuracies due to the change in format of such information. Another problem may arise because the parameters used to define how the historical data update is performed are static, and any change to such parameters requires that system 100 be taken offline.
It is an object of the present invention to provide an improved one-way interface between a source PI Server and a destination PI Server which overcomes the problems with the prior art.